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Abstract 

This is the tale of two different 

same design source. The Blueboard, ev ® °P . ] ar „ e display surface for walk-by 

information in a lightweight, informal collabora ive way d At na sa, the 

use i„ a corporate setting and has evolved Rover 

MERBoard is being designed to support surface opera, tons fo ^pcom * this design to 

annotating, linking and debuting tnfomtation for the 
See and engineer^ teams that will operate two rovers on the surface of Mars. 

Lessons about how task tenements, information flow requirements and work praerioe drive the evolution 
of a system are illustrated. 


1. Introduction 


varying demands of different communities and their patterns ot use. 

BlueBoaid began a, IBM's Almaden Research Center mid, ear 2000 Wh ° 

wanW to^o^ ^wetwb^ed mfmmation ^a^ery ^ash^srmp erio^userSCi^^ ^ idea of a large, 

researchers (1 amble waies; saw a uiu emerge in space 

sharable, interactive display would solve information sharing and joint work tasks g 

mission coordination. 

We have been working together ever since to share ideas and iechnoiogy. and have seen how each of the 
two instances of the same idea have evolved over time. 

To tell the story, we first examine Lhe BlueBoard. its ongnud learned 

users. 


2 BlueBoard: Original Goals 

The BlueBoard is a badge^adef fOT^mona^IdCTtif^arion 1 (an 

resistive touch screen (from SMART Technologies L j; pc secured in a lockbox bolted to 

„d"srf fo, a variety of purposes - from point-of-sale .0 infomrairon krosks. H . 2, 3. 4] 


, no, dinar, use, the BlueBoard is intended for both ve^ 

walk away - all within 5 seconds), and for sma group co personal space, compare notes, share 

around the BlueBoard to sketch ld ^P ull u P^ : 3 ™^°^ was primarily intended for the first role - rapid 

In our design, a BlueBoard has no heybo.d or fas, 
BlueBoards become just another personal compute believe that providing full keyboard 

rr BliBonnan Lvantas 8 . 



Qlir f oop nfferina fast access to personal 

Figure 1. The BlueBoard is a large, interactive display surtace oTOnng ^ de The disp|ay 

<ft» ** — ■* ^ son ident “ Network 

the badge's untque identifier is sen, to a Badge Server database that «„, hen,. rates the 

user handing back a URL to that person’s personal con tent. 

^tofs^ngyonrbadgehythe^nynp^— 

L a P^nVhome page- is no, , .lately 
displayed, but becomes available only by explicitly touching one s p-con. 



is created elsewhere, linking high-value information to web content. 


We are currently working towards a simplified BlueBoard content 
simple templates to link personal content to the BlueBoard server. 
BlueBoard, simple content creation is part of the entire BlueBoard 
content creation tool is beyond the scope of this paper.) 


authoring tool, one that provides very 
While not intended to be used at the 
use cycle. (The discussion of such a 



sensors 

(Cadge reader, 
camera, miciopfione, 
kx&ion sensor .) 



Fiaure 3 A BlueBoard links backend content (on a Webserver) with presentation on the large plasma 
display U toudhsween and badge reader. The badge ID is sent 

either an “unknown user" error, or an authenticated set of URLs in the Content Database^ 
is that a user "logs in” by simply swiping their badge at the display, getting rapid access 

content. 


Appliance Design for Personal vs. Communal Uses 

There’s an inherent design tension in large public displays: they are good for group work with peers 
Ending Tulder-to- shoulder, working together, but they are also very handy for 

person information access. Unlike other information appliances these device Sto^teck their 
users and multiple users. It needs to work for a single person walking up to the BlueBoard to check th 
calendar, and .'needs to work for small groups of people working together. Consequently, there -e two 
very different sets of overall goals: design the BlueBoard for individual information access, and des. D n 
BlueBoard for multiple people using the display at the same time. 

We have come to recognize that several design points need to be satisfied to balance these competing 
Isign goals These basic design issues are: (l) representing a person who’s participating m a session at the 
BlueBol-d (2) providing adequate tools for use at the board (e.g., a whiteboard function, a map of the 
JTZ ind personal information prtva.e while mak.ug location-based mformatton avatlable. 


2.1 BlueBoard in Use 


Representing a person: P-cons for access & sharing 

When more than one person is using the device, the device needs to know whose content is _ being viewed. 
There also needs to be a way to easily share content among the users who are all using the board 

same time. 

The p-con is just an image of the person representing that person's content. When a ™‘P e • * 

person's p-con appears in .he p-con dock on the right side of the d, splay see Figure 2). When more than 
person is at the board, all of their p-cons show up on the display (currently up to six). 

The P -con becomes the rapid access point for personal content. A user sets up 

linkine items such as calendars, presentations, continually updated information (stock quotes, P J 

«s 8 e“" o^ Te home page. tL. once badged-in to the BlueBoard. a finger much on the p-con brtngs 

up the first page of their content. 

The p-con is also the way to share information between simultaneous users. If one user is showing a slide 

horn' their content or an especially interesting web page, a drag-and-drop a P ‘ 

con will deposit a copy of that content in the p-con. When the p-con s person badges out (leave s the 
BlueBoard session), the contents of the p-con is e-mailed to them. In this way, sharing ! mfonn 
extremely simple - when you see something you like, just drag it to the p-con and the content is shared. 




Since all content shown on the BlueBoard is some variant of a web page, dragging (e*. 

a block of text or a picture) just copies that item into the person s temporary p 

ofUve entire page, the use, will drug from a "whole page" handle (,he idle har) fo ,he p-eon. 

In essence ,h« p-con siores eon.en. until ihe use, badges out A, badge on, time, the contents of the p-con 
buffer are packed up into an email message and sen, off io the p-con owner s email space. 

We have consciously avoided overly complex mechanisms such as group management or automatically 

sham content, and shanng is done by logically moving sham mate™ 1 ;„.o h m 
WP - VP attemDted complex window management schemes for doing split screens, y 

To dc" “Ty ihaTaLs ,h. spit, semen be s.mple io expla.n and use. It's too easy .0 become 
confused between foreground and background. Since an overriding goal is simplicity, we * 

return to those roots in making design choices. 

Tools for Rapid Use in Place 

Public shared communal devices all need to be extremely simple to use and must be intnnsica y use u 
even wito.Tpecia, registration. We wan, people ,0 he able io simply walk „p to a BiueBoard and do 

useful work. . r 

To date we have built a simple toolbar that allows a passerby to gain immediate access to severa unc 1 
r£=ng .cola calendar that shows the current day , week ( month. and a iocal map 

(showing the location of the BlueBoard in the local building). 

These functions continue to be accessible after badging in as well. As with al ^ r ^ ontent sh ° Wn 
BlueBoard, this content can be dragged to a p-con for shanng vta an email connection. 

Transient Information Must Be Truly Transient 

When a user badges in to the BlueBoard, their content flows to that location. When they badge out the 
content stored in the p-con buffer (if any) is emailed to the email address of their choice P^pectfied 
BlueBoard user registration time). But equally importantly, any content that was pul = BlueBoard 

from the remote content server must be purged from the local system to avoid the possibility 

compromise by later walk-up users. 

To make this assurance the BlueBoard tracks each content item as it comes into the system, tagging! w 
A, badge-out time, ail such content is explicitly removed (mcludmg hems ,» the 

history list and any cookies that might have been created in the process). 

BlueBoard Knows its Place 

A BlueBoard is a relatively static device. Weighing in at somewhat more than 68 kilograms (15 poun s), 
it is not an easily portable pocket-sized gadget. 

When the BlueBoard is nor in use, we have found it useful to have it show a loop of content page* “are 
™ “am o the location. In on, meeting room setting, the BlueBoard purs up projec, web pages and o he, 
wiJ s“es o local interest (such as the IBM home page, the IBM research home page, news s tes. etel The 
Sam loop'Tor page display is driven by a local list of pages drat is .adored 1. the sue and time. Pages 
are shown for a few seconds, then dissolve via an alpha-blend to the next page. en t ese pag 
Town The .ouch screen is slid active. If a passerby finds the page of pamcula, interest, jus touch the 
) ' Z the looping Slops, giving full web browser capability. (We discovered . hat people often 

» *e boL ,n time to s.op , he display. So we added a "back” button .he lower ngh, comer, 

which works in the way you’d expect.) 

We are working towards giving the BlueBoard a better sense of where it’s located. Ideally, location 
*f™T„Tro 8 u!rbTde,Li.=d by a locator beacon (eg., a in-room BlucT.oth devree, and then used ro 
determine what pages would be of local interest. (Say. lab project pages would be shown on the lab 
d B ?„“d, while corporate wide interest pages would he shown on a BlueBoard placed m .he foyer.) 



Similarly, we have done initial tests allowing people in a workgroup to em.,1 ™ssag“ 'o the BlueBoard 
“top, much as was done in the Lens shared public display at Apple’s research lab [61 . 

BlueBoard Users and Futures 

Our original destgn was , mended to support very lightweight sponhineous m~ungs of In 
we’d noticed that colleagues anytime and nearly anyplace (where there was a B lueBoard ). h £» stud.es 
we’d noticed that colleagues often have spontaneous meetings - in hallways, at lunch, while passing 
someone s^oor - and people often wanted to be able to show something, take notes or sketch an idea 
quickly and without carrying a great deal of mechanism. 

But this vision quickly ran into the realities of deployment and provisioning BlueBoards ubiquitously. e 

- 


3. MERBoard: Original Goals 

The MERBoard currently being developed at NASA’s Ames Research Center, in collaboration with the Jet 

m * * - » >* ■*-? «■? r 

information to support the operation of two Mars Exploration Rovers (MER) on thesurface ot Mars 
2004 The MERBoard design was inspired by the Blueboard, from IBM Research. The designs o 
Blueboard and MERBoard have diverged as the development of each responds to the needs and work 
pmletf u”t“n ti«ti Luted domains. The cutrent MERBoard design, intended m support tele-robotic 
Lienee is the result of a human centered development process. It incorporates both instghts derived trom 
ethnographic study and analysis and feedback from a participative design process. 

The goal of the MERBoard is to foster collaboration among scientists and engineers as they analyze science 
Ta develop Lienee plans based on that data, and turn those science plans into commands that are 

. , r th a/TFR Rovers for execution on the surface of Mars. As designers, we are stnvi g 

““ “ -ITS O Z Z Lius amonn, of teaming and specialization already regutred 
Z SXStiim, our goal is ,0 provide users with a too, whose basic functions and operations 
are quickly grasped, and one that can be used after 10 minutes of training. 

The MERBoard Domain - Mars Rover Surface Operations 



Rover acts as a remote fieid geologist on Mars 
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Figure 4 - Mars Exploration Rover and science instruments 

The MER Rovers will act as remote field geologists, providing scientists on Earth the ability to explore and 
learn about the Martian surface. Scientists and engineers will communicate with the rovers each day 
Sze the data transmitted form the rovers to Earth; use that data to develop the strategy for what m 
study next; decide how to implement the strategy; and then send instructions for activities, in the form 
commands, that the rover will implement. (Figure 5). 
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Figure 5 -- The rover operations team on Earth communicates with the rove 


every day 


As shown in Figure 4, each rover has two kinds of instruments, one kind to conduct remote sensing 
measurements, the other for in-situ measurements. This allows the rover to operate in a manner somewhat 



analogous to how a human field scientist would explore on the surface, viewing and analyzing the 
landscape from a distance (remote sensing), then deciding what to inspect more closely (in-situ). 

The MER mission is now in development for a mid-year 2003 launch and surface operations in 2004. The 
surface operations will include the process in which engineers and scientists receive and assess the 
“downlinked” data, make decisions about what to do next, and “uplink” or send related commands to the 
rover. The work process, communication flows, software, hardware and operational interfaces between 
groups are currently being developed from documentation and requirements. Models of mission operations 
are being worked out in paper based designs. 


A day in the life of the Mars Rover Surface Operations Team will begin with the receipt of data from the 
rover. Scientists will view and analyze that data and assess the resulting information to identify potential 
targets for inquiry. The science team will work in five different theme groups, atmospheric science, 
geology, geochemistry and mineralogy, soil/rock physical properties, and long term strategic planning. The 
theme groups must translate their inquiry into a strategy of prioritized scientific observations. The strategy 
will be formalized into representations for presentation to the engineers who will develop commands to 
carry out the requests. In order to do their job, the scientists will need to collaborate and make decisions 
within and across theme groups and as a team. 


With each step in this daily process, the degree of formalism with regard to the science strategy increases. 
Early in the day new ideas for inquiry may be represented on flip charts and in notebooks. Then the 
scientists use the Science Activity Planner tool to turn the inquiry into complete observation requests, with 
instrument settings and parameters. By the end of the day, the ideas have been turned into formal 
representations that have moved through a variety of computer tools specific to each stage of the uplink 



Figure 6 - Scientists Training for Mars Surface Operations. The two large displays are just 
projections, not MERBoards. Note the actual interaction work is taking place on large pieces of paper 
attached below the projected image. 


Understanding and Augmenting Work Practice with HCC Methods 

As Human Centered Computing (HCC) Researchers, our goals for the mission are to increase mission 
safety and science productivity by working with the mission team to design tools and procedures that help 
the users accomplish their tasks, while minimizing the complexity of the tools. To achieve this for MER, 
we model and characterize user work practice based on data gathered in interviews, observations of training 
exercises, researching requirements documentation, and our own participation in parts of the design 
process. 

Figure 6 shows the science team at work in a series of Mars Yard and “field” tests that took place in 2001. 
The tests simulated the process of doing tele-robotic science, commanding a remote rover and collaborating 
to make science decisions. Note the use of flip charts, laptop computers, print outs and projection screens 
that display information from the team’s Science Activity Planner tool. 

Ethnographic observation and analysis, as well as interaction analysis [XX] of video or film taken during 
the above field test simulation, revealed limitations on the collaborative process. Specifically, we saw 
limitations on the ability of scientists to display, share and view important information, and limitations on 
their ability to save information. For example, the flip charts preserve the ability for natural, rapid, 
handwritten representations, and they are large enough to present to small groups of people who are co- 
located. They do not allow for the embedding of related information, such as images. They are difficult to 
store and retrieve over long periods of time, and they are not easily shared beyond team members who are 
in close viewing range. 

In another example, scientists often had important supporting data on their laptops they could not share in a 
form the rest of the team could see. In Figure 5, the projection screens facilitated group viewing of some 
information in the computer tools such as the Science Activity Planner, but they were not configured to 
allow users to show their laptop data on the large projection screens. 

The MERBoard design is intended to assist the mission operations process by addressing direct user needs 
that we observed in training, such as the ability to display, annotate and share information in a natural way, 
much as the team was already doing with flip charts. By inserting the MERBoard into the mix of tools 
shown in Figure 5 above, we propose to augment the teams existing work practice and to provide additiona 
functionality that could enhance the science process. 

The initial MERBoard design was developed based on an analysis of observations similar to those 
described above. With the HCC method, we can identify user needs and even propose new work process - 
we cannot predict with certainty all the effects of the introduction of a new tool into the mission operations 
process. Users will soon be able to test the prototype designs and will be able to provide us with direct 
feedback. As the MER Team begins formal training in 2003, they will be able to use the MERBoard in 
scenarios that simulate the mission. The MERBoard design team will observe this process to evaluate the 
impact of the MERBoard on work practice, as well as to assess the effectiveness of our HCC design 
process. 


3.1 The MERBoard for Mission Operations 

The MERBoard hardware consists of a commercial off the shelf 50” plasma display with a touchscreen 
overlay and custom designed stand. The current software version consists of a Web Browser for data and 
file viewing a workspace application that allows users to display and annotate images or any data 
displayed on the screen, a virtual network computer (VNC), a screen capture tool, and personal account 
space accessible on any networked board. 
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Figure 7 — The current MERBoard Ul Design 


Figure 7 shows the current MERBoard user interface design. The tabs on top allow a user to select the 
browser, the workspace, the virtual network computer, or their own personal MERSpace files. On the right 
are color coded “stickies” The tabs on the left provide access to users, groups and other MERBoards. On 
the bottom, are the icons for the mail and screen capture tools. 

Figure 8 shows the MERBoard hardware, the large plasma display with touchscreen overlay, and a 
specially designed rolling stand. A keyboard and mouse are currently being used for evaluation purposes, 
but are not considered necessary to operate the board, as the touchscreen is the primary input method. 

Viewing and Real Time Sharing of Data 

The MERBoard by virtue of its large plasma display, makes information easily visible to groups of people 
close to the board. The VNC allows any user on the network to view the contents of any MERBoard, either 
from their own personal computer, or from another MERBoard. With VNC, team members will be able to 
display and share the scientific data on their laptops with the larger group. Additionally, VNC extends data 
viewing and sharing throughout the mission support area and makes one group’s data accessible to all team 
members. With the MERBoard, scientists can view the work of the other theme groups, enhancing 
information sharing and expanding the knowledge base for the whole group. In principle this sharing 
capability can be extended to remote sites, providing team members who are not in the primary mission 
support area at JPL the ability to participate in the mission process. 





Figure 8 -- MERBoard Software on large plasma display with touchscreen overlay 

Viewing Data and Data Annotation 

The MER Science Team will analyze images and other data on a daily basis. They will view images of the 
Martian landscape to determine where they would like the rover to go and what features, rocks, cliff face, 
soil etc., they would like to analyze with their instruments. They will also view images representing 
multiple scales of representation from panoramas of landscapes to microscopic images of selected features. 
After they analyze data, they will develop hypotheses, select new targets for inquiry, and implement 
science observation strategies to get data from those targets. 


The MERBoard is designed to facilitate easy capture and display of multiple images. While much of the 
science analysis will be done in the science activity planning tool, the MERBoard workspace will make it 
possible to compare and annotate images, either free hand, with a limited set of drawing tools, or with voice 
annotations. We believe, the ability to support natural annotations and link it to information will contribute 
to the decision making in the next step in the process, which is the formal specification of science data 
requests. 


Figure 9 shows one example of work practice from the field tests. Team members referenced print outs of 
large images in the mission support area, using various improvisational devices to point to and reference 
different details of the image. While we believe that the scientists will still want to look at large printed 
images in the mission support area, we also believe that the MERBoard, by allowing for the electronic 
display, annotation and referencing of images of different sizes and resolutions, has the potential to increase 
the science team’s productivity and aid the decision process. 



Figure 9 - Science teams working with large (offline) photos. Form factors count for a great deal 
when working in with many people on large amounts of visual data. 

Sending and Saving Data 

The MERBoard design has several mechanisms that allow for easy sending, saving and retrieval of data. 
E-mail: Pages from the MERBoard’s workspace may be easily e-mailed to any other MERBoard user with 
a simple drag and drop interface. The scientists already have email accounts and presumably check the 
regularly This functionality leverages existing software systems and knowledge. No new software 
development or training is required in order for scientists to be able to share information with team 
members who are not present. 

Save to MERSpace: Each MERBoard user has an individual storage space on the MERBoard^ This space is 
accessible from any MERBoard with a simple log in, and is also accessible from a MERBoard Client 
Users may save data to their own MERSpace with a simple drag and drop. The current interface does not 
allow users to save information to another person’s MERSpace as our current working assumption is that 
users are unlikely to regularly check their MERSpace in-box for data sent from others; e-ma.l is used 

this purpose 

Save to an Archive : During and after the surface operations of the mission, it is highly likely that scientists 
will want to retrieve information that allows them to recreate the context of events and support their 
analysis of mission data. Also, MER is an historic mission and it will be important to retain documentation 
to understand the scientific process and recreate a mission history. Additionally, because this is a research 
project, we must offer several ways for scientists to save data in order to evaluate what was useful fo 
participants during the mission. Therefore, we will provide a functionality that allows group members 
save data with key words as well as “metadata” that already exists in the board. Examples of meta-data 
include time, location and name of the board, date, Martian Sol (a Martian Sol is the rough equivalent 
Earth day, i.e. a Sol is 24.7 hours), and other parameters that do not require users to specify them. 

4. BlueBoard: Lessons Learned from Early Testing 

In normal use, the BlueBoard is a place where a small number of people can quickly and easily work 
together. A major question is what would actually happen in small group use. 

We ran a field study of the BlueBoard in use by small groups at a workshop held at the IBM Almaden site. 
Badges were given to 163 participants, 90% from outside of IBM or Almaden, and with no advance 
knowledge of the test. The database was initialized with their email addresses and pointers to their home 

pages. 

At the beginning of the workshop, a brief 4 minute demonstration of the BlueBoard was given to all 
participants simultaneously, and the BlueBoard was made available in the hallway mmied.ately outside the 
auditorium for non-directed use during the breaks and an extended lunch. (The BlueBoard was one of 
many demonstrations in the hallway.) The instruction covered badging-in, access to one s home page 


through the p-con, exchanging URLs, use of the whiteboard tool, sharing whiteboard content between 
badged-in people, and badging-out to cause shared content to be automatically emailed away. 

Users of the BlueBoard were videotaped in used, and six were given a post-use informal interview that 
asked questions about their goal in using the board, particular problems they had, and possible future 
extensions. 

During the 110 minutes of BlueBoard availability, it was nearly constantly in use as participants would 
walk up, badge-in and begin exploring its capabilities. Although no task was set, we saw several 
apparently authentic work uses of the board during the time we observed. These included demonstrations 
of participant website development (“let me show you this great thing I did.. ), explicit sharing of web 
pages, and uses of the whiteboard for non-trivial diagrams. 

After the workshop, we collected our field notes and analyzed the video. 

As would be expected, we learned a number of pragmatic user interface lessons from our observations: 
inconsistencies in the UI widgets and idioms, the particular difficulty of using a touch screen with long 
fingernails (they generate an uncertain touchdown point on the resistive touch sensor), how high we can 
place elements on the screen to be used by short people, and so on. 

Observations on Group Use 

Although we were initially simply looking for instances of authentic work-like uses of the BlueBoard, and 
the degree to which all the BlueBoard features could be used after such short instruction, we were struck by 
the number (and importance) of social interaction effects that took place. Here are the six most evident 
effects we noted in our analysis: 

1. Social learning through exposed interaction : The interface style of the BlueBoard is evident - a user 
can only touch parts of the display to make things happen. Consequently, the entire interaction process is 
visible to everyone - there are no hidden keystrokes or sudden mouse movements that are difficult to 
understand. Participants who are unsure of how to use a particular function of the BlueBoard were able to 
very easily see how someone else could do the thing they wanted. In the course of study, we saw many 
examples of someone picking up a behavior by seeing someone else use it m the course of their interaction. 



Fig 4 BlueBoard setup in the field study. The whiteboard tool is always one touch away from instant 
use. The image can be dragged onto the artist’s p-con or onto another p-con to be emailed when that 
person badges-out. In this video sequence, the user controls the use of the board while three other 
users watch, waiting their turn. 


2. Etiquette of multiple person use is unclear : When a group was using the BlueBoard, other participants 
were often uncertain about what kind of behaviors would be acceptable. Should one badge-out while 
another person was engaged in making a point? Was it permissible to badge-in without making any kind of 
verbal comment? Time and again we saw hesitations as new BlueBoard users struggled with these 
momentary crises. Similar issues arise in any kind of workgroup that is focused on a shared information 
resource (including non-electronic) - what are appropriate behaviors for engaging and disengaging? [11] 



We believe these questions will subside over time as board use becomes more commonplace and practices 
evolve. (See Figure 4.) 

3. Who drives? Groups using the BlueBoard often tended to have one person dominating the interaction. 
Usually, this was the person doing work at any one moment, either by showing group members their 
content ’navigating to a web page to show a result, or working on the whiteboard. Less frequently, but 
encouragingly, we also saw several instances of small groups (2-4 people) where there was NOT an 
obvious group leader. These more cooperative discussions were almost exclusively whiteboard drawing 
sessions where tumtaking was rapid and fluid. 

4 Learning to work together - evolution of turn- taking: It happens that the BlueBoard touchscreen cannot 
handle more than one touch point at a moment. If two people touch the screen simultaneously, the cursor 
jumps to the midpoint between them. When two people are using the whiteboard tool together, it is 
immediately obvious to the drawers that this is true, and a turn-taking practice rapidly comes into place. 

We note with some satisfaction that complex floor controls were never asked for nor needed. Instead, 
because the people drawing could immediately see the consequences of their actions, and because they 
were physically adjacent, they could easily tell when their partner was about to draw and coordinate their 

joint actions. 

5. Reaching across: The size of the BlueBoard is an important determiner in the way groups of people 
work with it In the small dynamic workgroups, 2, 3 or 4 people would stand effectively shoulder-to- 
shoulder, each person reaching in to touch and operate the BlueBoard. By contrast, when a single person 
was leading the discussion, they would tend to stand in front of the board with other members (from to 
others) making an arc in front of the board. We noticed many instances of hesitation when controlling the 
board required reaching across another person standing in a controlling position. That is, like reaching for 
a plate at the dinner table, participants considered the reaching maneuver to be perhaps slightly ru e - an 
an assertion of control over the proceedings. 

6. Group sharing of information: As others have pointed out, shared information artifacts need not be 
electronically based, but simply available to many people simultaneously. [11] When such shared disp ays 
are being created and edited in real-time, there is a distinctly opportunistic use of the information being 
used in the meeting. Even when a single person is controlling the flow of events, being able to share the 
experience of editing in situ provides additional important side -channels of information exchange. In our 
study we noted several instances of side-comments being incorporated into the flow of the discussion; 
comments that might have never been a part of a virtual discussion. 

Observations on Individual Use of BlueBoard 

In addition, we had several observations about individual uses of the BlueBoard. 

1. Text input: Although participant home pages were not optimized (or even minimally set up to take 
advantage of the BlueBoard), it didn’t seem to matter except in cases when text input was required for 
search or login. Since search strings tend to be short, a virtual keyboard of some kind will suffice. But 
login authentication requires typing in a password, and as noted above, a BlueBoard / LISA class device is 
particularly accessible for co-participants in a group setting. In the field study, no keyboard was available, 
so participants simply did without, but it is a problem that will have to be resolved. 

2. Drawing is important: The whiteboard tool was put into the BlueBoard initially as a small drawing 
capture area. Over time, though, we have been consistently surprised at the utility of the whiteboard tool 
and the novel uses people have found for it. While the whiteboard tool is currently very simple (simple 
vectors drawn point-to-point by finger-dragging), the simplicity of the tool, its attractive similarity to 
fingerpainting, and most importantly, its automatic capture via being emailed as an attachment, all led to a 
wide number of uses. One of the unexpected uses noted during the field study was the number of times 
people would write their email address and drag it to an acquaintance’s p-con. This would effectively send 
the recipient an image with an email address in it - quickly and simply, all without typing. (Similar 
instances of people scheduling appointments by writing times, dates and places were also seen.) 

3 Easy to use: Of the six behaviors shown in the introductory four minute demonstration, we saw all of 
them in competent use by first-time users. Some of the skill users demonstrated was clearly due to social 


learning through observation, but we were pleased to find that the affordances of the interface were fairly 
apparent. 

4. Few badge-outs'. On the other hand, the one behavior that was problematic was badging-out when 
leaving the BlueBoard area. Nearly everyone who had do some work (e.g., created a whiteboard image or 
saved a URL to their p-con) successfully badged-out. But around 50% of those that did not capture an 
image or other content failed to badge themselves out of the BlueBoard. (The number is approximate, 
plus-or minus 10%, because we did not accurately track badge-out events.) 


5 . MERBoard: Lessons Learned from Early Testing 

Initial User Reactions 

We introduced the first version of the MERBoard tool to many of the scientists who will participate in the 
MER mission at a meeting in January of 2002. After demonstrating the functionality and operation of the 
tool, we invited participants to use it and offer comments. 

Generally, participants were enthusiastic about the ease of use and were impressed with the large plasma 
display. One participant even quipped, “How much do these things cost? I want one in my office. The 
science team documentarians quickly saw ways that the board could enhance their work with the addition 
of functionality that would allow them to package and group documents and images. 

Other users were enthusiastic because they saw the board’s possibilities as a remote collaboration tool, 
believing that it could provide them with access to updated information on the progress of the mission 
while at home. Because of security issues during the mission, however, we do not know whether the tool 
can be used for remote collaboration. 

Team members were more cautious about the tool’s design and benefit when it came to logging in and 
sharing space. Because of the large number of team members who might be using a board at any given time 
and the fact that they would work in groups, they had questions about the log in process, the use of P- 
cons,” and how the team would use the tool when several people were participating in the discussion, 
sharing a workspace and annotating data. They were undecided as to whether they needed the ability to 
track and identify individual annotations and changes in the information. Some scientists wanted the ability 
to save annotated data to an archive; others did not. There was a discussion about the possible challenges 
of making group decisions with regard to saving or deleting shared information. 

Some participants liked the ease of sending information from the board via email. Others were openly 
skeptical about the value of getting more email. They were more receptive to a proactive approach that 
would let them go and get the information they wanted from an archive. 

There were questions about how individuals could prepare and post information to the board for later 
display, questions about how the client version of the software would work, and security questions in 
regard to VNC. 

We got many UI comments. Users wanted: 

• feedback that let them know that an action has been accepted 

• an undo button 

• different placement of tabs and buttons 

• double touch actions, as well as drag and drop capability 

• grid lines to keep the writing neat so that it was easier to read later 

• rulers for measurement 

As observers, we noted that participants had some difficulty using the plasma display. People had to learn 
how hard to press on the board, how to write and annotate easily, how to use finger touch in scrolling. 

All of this feedback has been considered in later design decisions. 


6. Common Lessons 


Differences between MERBoard and BlueBoard stem primarily from the two vastly different intended user 
groups and their expectations for work group support. 

Differences: The BlueBoard has no keyboard, and in some installations is located in a passageway without 
a place to sit or work for extended periods. The expectation originally was that BlueBoards would be used 
largely for ephemeral purposes - for spontaneous demonstrations or rapid access to information for 
immediate use. By contrast, MERBoard is aimed for work sessions that may last for extended periods of 
time, with a fairly limited and technical user audience. The kind of work practiced by the NASA team is 
fundamentally different than that of BlueBoard users - it centers on accessing content, then annotating it 
and linking content with other pieces of information, storing and retrieving data, as well as on display and 
information sharing among and between groups. As a consequence, several of the design decisions made 
by BlueBoard (lack of keyboard, unavailability of remote computer access, the use of p-cons for locally 
logged-in people) worked against the goals of the MERBoard users and nfceded rethinking. The 
workpractice that the MERBoard will support calls for more complexity in the conceptual model and in the 
design of the tool than is called for by the intended use of the Blue Board. 

Similarities: Both projects had to rapidly evolve in the face of requirements to fit into the tasks of their 
respective working populations. In both cases, lessons learned during early deployment led to substantial 
changes in either the interface design (MERBoard) or the goals of the overall project (BlueBoard). While 
both projects continue to advance, it is clear that such analyses of fit-to-task and fit-to-overall-goal need to 
be evergreen reflective aspects of the project. In both systems, it has become apparent that no amount of 
upfront analysis would ever have been enough to pre-determine all of the requirements and properties that 
would be needed. A priori analysis is useful, but only in a systems development environment that also 
allows for significant changes to happen after actual first pilot testing results have been collected and 
analyzed. 

8. Summary 

It’s clear that user-centered design is required for any kind of project that has a significant user-facing 
aspect. Even projects that seem superficially similar - such as supporting team work at NASA and for 
knowledge workers at IBM Research - turn out, in the analysis, to be significantly different. Those 
differences drive the evolution of the system. A key aspect in the development of these two systems has 
been a continuing theme of reassessing the design’s fit to users and fit to task: such evolution needs to 
happen on a relatively rapid time scale in order to be useful to the user population and to retain interest and 
capability in deployment. 

In the future, as MERBoard and BlueBoard progress and our understandings of the use patterns in each 
environment grows, we hope to find an increasing number of common shared ideas and user behaviors. 

This second level of analysis will, we believe, lead to the basis of a set of practices that will emerge in the 
area of publicly available, large, shared and interactive display surfaces. 
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